SCA Service Component Architecture provides an open, technology-neutral model for implementing IT services that define a business function. The SCA also provides a model for the assembly of business solutions from collections of individual services, with control over aspects of the solution such as access methods and security. With a SCA, customers are able to more easily create new, and transform existing, IT assets into reusable services that may be rapidly adapted to changing business requirements. The specifications that enable the building of SCA (middleware) components take advantage of a Service-Oriented Architecture (SOA), which structures IT assets as a series of reusable services that perform business functions. The Service Oriented Architecture combines the ability to invoke remote objects and functions (called “services”) with tools for dynamic service discovery, placing an emphasis on interoperability. Currently, a goal of the industry is to provide application developers with simpler and more powerful ways of constructing applications based on SOA.
Moreover, in the development of distributed systems implementing SCA components, it is a goal to provide for transparent and fault-tolerant availability of ‘non-volatile’ data that may either represent persistent ‘settings’ (to be stored on mass-media throughout the distributed system) or ‘state’ preserved in a fault-tolerant manner. Presently, the development of distributed fault-tolerant and highly available systems is ad-hoc, error-prone, and time-consuming. Current solutions are analogous to an example currency exchange system where the fluctuation of currency price and exchange operations may be out of order or non-atomic. Execution is usually non-deterministic due to the network or threading: Existing mechanisms for persistence (entity beans, JDBC, etc) are heavyweight and they necessitate extra knowledge and extra code.
For example, a current solution implements entity beans, e.g., “Enterprise Java Bean” (EJB) that includes the server-side component architecture for the J2EE platform. EJBs purportedly support rapid and simplified development of distributed, transactional, secure and portable Java applications. EJBs support a container architecture that allows concurrent consumption of messages and provide support for distributed transactions, so that database updates, message processing, and connections to enterprise systems using the J2EE architecture can participate in the same transaction context.
It would be highly desirable to eliminate the need to require programmers to learn specialized methodologies and structures such as transactions, JDBC, or entity beans that separate out component state into separate objects and to persist that state, and, instead, to automatically provide persistence and fault-tolerance for ordinary code (known as “transparent fault-tolerance”). Many applications perform computations that depend only on input data and do not explicitly account for the time needed to execute the necessary code. Such applications are known as being “non-time-aware”. Other applications, knows as time-aware applications, require different decisions be made based upon the execution speed of the running system. For example, taking a default action when no event has arrived by a certain time, or performing a faster computation, at the expense of less precision, when a slower and more precise calculation may deliver a result too late. It would be desirable for an execution environment to support non-time-aware applications transparently as well as providing interfaces for time-aware computations.
There do exist techniques for transparent fault-tolerance in distributed systems, including a technique described in U.S. Pat. No. 4,665,520 commonly owned by the assignee of the present invention. The performance of such techniques is limited by the non-determinism of the behavior of communicating components in distributed systems, as each communication from one distributed component to another needs to be logged.
Moreover, it would be highly desirable to provide an execution server that transparently supports deterministic execution, fault tolerance, and high availability, to avoid the performance problems of recovering non-deterministic distributed systems. It is known that there is a certain overhead in implementing deterministic execution, as in the foundational invention. It would be desirable to introduce improvements to minimize this overhead. Furthermore, it would be desirable for such systems to be efficient in the presence of a certain amount of inevitable non-determinism that can arise in time-aware applications.
Furthermore, it would be highly desirable to provide a simple component-based model for programmers and, particularly, to provide a system and method for making middleware functions more accessible to the application developer.